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ABSTRACT 


The  need  for  a  project  information  and  control  system  at 
FNOC  was  examined.  Personal  interviews  and  checklists  were 
used  to  determine  user  requirements.  Several  manual  and 
automated  alternatives  were  presented.  The  author  concluded 
that  the  purchase  of  a  software  package,  would  in  all  prob¬ 
ability,  be  the  most  efficient  and  effective  alternative. 
Several  packages  were  evaluated  and  3  packages  were  finally 
presented  for  more  extensive  review  by  FMOC  staff. 
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PREPACE 


Throughout  this  thesis  the  reader  will  find  three  cate¬ 
gories  of  statements.  Scientific  facts  are  those  statements 
that  are  supported  by  scientific  research  in  the  field. 

These  stateaents  can  be  identified  by  a  direct  reference. 
Authors  opinions  are  specifically  identified  as  such.  All 
other  statements  can  be  classified  as  General  nanagenent 
lore.  This  type  of  statement  refers  to  generally  accepted 
theory  in  the  management  field;  however  it  is  unsupported  by 
scientic  research. 
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I.  INTBODUCTION 

In  an  environment  characterized  by  increased  numbers  of 
projects,  drastic  increases  in  deoands  for  information,  and 
strong  limitations  on  personnel,  computer,  and  financial 
resources.  Fleet  Numerical  Oceanographic  Central  (FNOC) , 
must  look  at  alternative  courses  of  action  to  maintain  an 
effective  level  of  performance  in  project  management. 

It  is  the  intent  of  the  author  to  examine  the  need  and 
information  requirements  for,  project  information  and  con¬ 
trol  system  (PICS)  at  FNOC.  This  system  should  not  only  pro¬ 
vide  for  the  flow  of  pertinent  project  information  to  top 
management;  but  also  assist  the  project  manager  and  other 
middle  managers  in  estimating,  assignment,  and  scheduling  of 
project  tasks  and  resources.  Alternative  courses  of  action 
will  be  identified  and  available  software  packages  examined, 
to  determine  their  capability  of  meeting  those  requirements. 

This  document  will  provide  to  FNOC  management  assistance 
in  selecting  the  appropriate  course  of  action  as  well  as 
providing  a  preliminary  analysis  of  user  requirements. 

Prior  to  examination  of  FNOC's  project  management  needs, 
a  review  of  the  literature  relevant  to  project  management 
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will  be  provided.  Specifically,  there  will  be  an  examination 
of  several  of  the  problems  associated  with  software  project 
management.  An  awareness  of  these  problems  will  assist  the 
project  manager  in  visualizing  the  importance  of  effective 


project  control 


II.  REVIEW  OF  PROBLEMS  IN  SOFTWARE  PSOJECT  MANAGEMENT 

An  increasing  percentage  of  DOD  monies  are  allocated  for 
direct  software  acquisition  or  embedded  software.  In  1977, 
the  United  States  government  estimated  the  cost  of  software 
development,  testing,  and  maintenance  to  be  about  $U  billion 
per  year.  At  that  time  the  government  owned  approximately 
$25  billion  worth  of  currently  used  software.  [Ref.  1] 
Overruns  of  100*  in  both  cost  and  delivery  time  have  not 
been  uncommon  occurrences  in  software  projects;  and  in  fact, 
there  have  been  cases  of  total  failure  to  develop  systems. 

There  has  been  a  great  deal  of  attention  and  speculation 
as  to  the  cause  of  these  problems.  It  is  the  author's  con¬ 
tention  that  effective  project  management  on  the  part  of  the 
contracting  project  manager  can  minimize  and  perhaps  elimi¬ 
nate  most  of  these  problem  areas. 

A  review  of  the  literature  surfaced  several  problem 
areas  in  software  project  management.  These  problems  are 
presented  here,  together  with  information  for  the  project 
manager  who  desires  to  minimize  the  risk  of  project  failure. 
Certainly  the  awareness  alone,  of  potential  problems. 
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will  increase  the  effectiveness  of  the  project  nanager,  and 
provide  direction  toward  project  success. 


PROBLEM: 

Poor  accountability  and  control  structure,  such  as: 

*  inappropriate  Measures  of  effectiveness 

*  Minimizing  development  costs  and  schedule 

*  emphasis  on  percent  coded 


The  first  method  of  control  starts  with  the  organiza¬ 
tional  structure.  Usually  the  project  organization  is  set 
up  to  meet  a  specific  objective  and  it  dissolves  after  it 
has  been  accomplished.  This,  in  itself  can  create  a  problem. 
The  manager  may  not  be  fully  aware  of  the  shills  of  the  pro¬ 
gramming  teams.  The  host  organization  must  therefore  strive 
to  maintain  accurate  docuaentation  as  to  those  abilities. 

Managers  must  also  decide  on  a  mangement  system.  There 
are  many  automated  aanageaent  control  systems  available  to 
assist  a  project  nanager;  however,  it  should  be  remembered 
that  they  must  fit  the  organization,  and  that  simply  because 
they  have  been  used  with  great  success  by  others  ,  does  not 
guarantee  their  success  in  all  structures  or  projects.  This 
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is  a  point  that  many  managers  fail  to  take  into  account  when 
they  are  looking  for  that  aagic  control  method.  In  matching 
a  method  to  the  organization  the  manager  must  take  into 
account  such  things  as  whether  or  not  project  management  is 
linear  or  matrix  oriented,  what  item  the  organization  is 
most  interested  in  tracking,  and  what  levels  of  reporting 
are  required. 

Establishment  of  a  project  control  room  to  centralize 
information  needed  by  the  project  team  might  prove  to  be  of 
value  to  the  organization.  Some  of  these  items  include: 
documentation,  master  schedules,  status  reports,  change 
authorizations,  budget,  systems  flow  charts,  edit  rules,  and 
user  training  information.  Consideration  might  also  be 
given  to  the  establishment  of  a  project  control  secretary 
position. 

Emphasis  on  percent  coded  tends  to  get  people  coding  too 
early  and  key  activities  such  as  requirements  and  design 
validation,  test  planning  and  draft  of  user  documents  are 
neglected.  It  is  also  true  that  percent  coded  is  not  indica¬ 
tive  of  where  the  project  is  relative  to  the  schedule.  It  is 
extremely  subjective.  To  combat  this  problem,  key  milestones 
should  be  set.  These  must  be  measurable  milestones.  For 
example,  milestone  1  might  be  acceptance/approval  of  design 
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criteria  by  the  user.  Involvement  of  the  user  early  in  the 
project  and  throughout  its  existence  will  help  to  iceep  the 
project  on  track  and  hopefully  surface  user  problens  early 
in  the  project. 

Structured  programing  techniques;  specifically  top-down 
design,  provides  a  procedure  for  organizing  and  developing 
the  control  structure  of  a  program  in  a  vay  which  focuses 
attention  early  to  the  critical  issues  of  integration  and 
interface  identification  and  definition. 

problem; 

Software  requirements  specifications 
(if  they  exist) 
are  often  ambiguous. 

These  requirements  must  be  written  by  personnel  knowled- 
gable  in  both  the  systems  requirements  and  software  develop¬ 
ment.  This  is  often  not  the  case,  especially  where  embedded 
software  is  involved. 

Technology  can  be  of  assistance  here.  Machine  analyzable 
software  requirements  systems  are  available.  The  pioneer  in 
this  technology  was  ISDOS,  developed  by  Teichroew  at  the 
University  of  Michigan  [Ref.  2].  although  it  was  developed 


primarily  for  business  systeas  applications;  the  United 
States  Air  ?orce  is  currently  using  and  sponsoring  exten¬ 
sions  to  ISDOS  under  the  computer  aided  reguireaents  analy¬ 
sis  (CABA)  program.  Another  even  nore  extensive  and  powerful 
system  is  one  developed  under  the  software  reguireaents 
engineering  program  (SREP)  by  TRW  for  the  United  States  Army 
Ballistic  Missile  Defense  Advanced  Technology  Center.  Even 
these  automated  systeas  have  limitations  however;  the  capa¬ 
bilities  to  represent  large  file  processing  and  aan-aachine 
interactions  are  liaited.  They  are  a  start  however. 

Often  a  project  aanager  will  inherit  a  project  which  is 
not  adequately  defined.  Realizing  this  and  taking  immediate 
steps  to  remedy  the  problem  is  necessary  to  project  success. 
The  extra  time  spent  at  this  point  will  pay  off  in  the  end. 
Because  of  the  nature  of  software  development,  errors 
detected  early  in  the  cycle  are  less  costly  then  those  dis¬ 
covered  in  later  phases.  Figure  1  [Ref.  3].  A  project  man¬ 
ager  must  avoid  the  temptation  to  allow  detailed  design  and 
coding  to  begin  prior  to  establishment  of  user  reguirenentts 
and  an  overall  plan.  The  extra  time  spent  in  the  definition 
and  design  phase  will  be  time  well  spent  if  it  minimizes  the 
likelihood  of  problems  in  later  phases. 
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PROBLEM: 

Software  testing  and  reliability  activities  are 
often  not  considered  until  the  code  has  been 
run  for  the  first  tine  and  found  not  to  work. 


In  general  the  cost  of  testing,  40%-50X  of  the  devlop- 
■ent  effort,  is  due  to  the  high  cost  of  reworking  the  code 
at  this  late  phase  of  the  cycle  [Ref.  4].  There  is  a  great 
deal  of  wasted  effort  resulting  froa  the  lack  of  an  advanced 
test  plan  to  efficiently  and  effectively  guide  testing 
activities. 

The  development  people  must  consider  the  testability  of 
their  design  and  ensure  that  code  can  be  exhaustively  tested 
before  the  next  higher  level  of  code  is  added.  Early  loca¬ 
tion  and  correction  of  errors  results  in  much  more  reliable 
programs.  A  solid  test  plan  should  provide  for  an  indepen¬ 
dent  validation  team  to  be  established  at  the  beginning  of 
the  project. 

The  consequences  of  undetected  errors  can  range  from 
minor  to  disastrous.  A  well  known  example  of  the  latter  was 
the  Mariner  1  interplanetary  probe.  The  absence  of  one  bar 
over  a  letter  in  a  computational  equation  resulted  in  a 
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unrecoverable  problem,  left  no  alternative  but  to  destruct 
the  $18.5  million  dollar  rocket  shortly  after  launch.  [Ref.  5] 
Reliability  can  be  improved  by  imposing  standards  on 
programming  style  for  all  code  written.  Structured  program¬ 
ming  has  a  lot  to  contibute  in  this  area.  Structured  pro¬ 
gramming  involves  dividing  a  complex  program  into 
progressively  smaller  modules,  each  of  which  has  a  well 
defined  task.  The  most  refined  modules  are  small  and  logi¬ 
cally  straight  forward.  They  have  limited  control  structures 
and  one  entry  and  exit  point.  The  conciseness  of  the  modules 
allows  the  programmer  to  use  formal  mathematics  to  prove  the 
correctness  of  the  code. 


PROBLEM: 

Cost  estimates  in  software  projects  are  often 
incomplete  and  grossly  inaccurate. 


There  is  always  the  element  of  risk,  especially  on 
projects  that  push  the  state  of  the  art.  Estimating  hardware 
costs  ha3  followed  established  methods,  software  on  the 
other  hand,  is  seldom  handed  to  a  software  estimating  group. 
In  fact,  software  estimating  seldom  follows  any  scientific 


18 


procedures,  with  perhaps  the  exception  of  those 
organizations  utilizing  PERT/CPH*. 

The  OOD  is  currently  evaluating  macro  and  micro  techni¬ 
ques  for  estimating  resources  required  for  ADP  projects.  The 
macro  technique  provides  an  overall  lump  sum  estimate  of 
manpower  and  costing  factors  for  the  entire  systems  life 
cycle.  The  micro  technique  provides  detailed  manpower  and 
costing  for  each  phase  of  the  life  cycle  fHef.  6]. 

Studies  by  industry  have  concluded  that  there  are  no 
simple  universal  rules  for  costing  software  accurately  and 
that  to  estimate  it  accurately  it  is  neccesssary  to  under¬ 
stand  the  nature  of  the  individual  program  [Ref.  7], 

It  would  appear  that,  the  problem  with  software  cost 
estimates  is  that  until  we  have  more  standardization  of 
procedures  in  the  software  industry,  the  estimates  will  con¬ 
tinue  to  be  grossly  inaccurate  due  in  part  to  the  varying 
programming  methods. 

One  pitfall  to  avoid  in  worrying  about  software  costs  is 
that  of  concentrating  too  much  on  reducing  software  develop¬ 
ment  costs.  what  really  needs  to  be  reduced  is  software  life 
cycle  costs.  Instead,  we  too  often  find  project  managers 

•  For  additional  information  on  PERT/CPH  see  Cleland,D.L. 

sgorS.-iifi?  i  tnj  fc<?'lw 
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making  a  lot  of  trade-offs  during  the  software  development 
to  meet  schedule  and  cost  constraints.  Han/  of  those  trade¬ 
offs  trade  maintainability  for  speed  of  development. 

In  a  discussion  during  the  1973  Symposium  on  the  High 
Cost  of  software,  it  was  pointed  out  that  the  avionics  soft¬ 
ware  in  the  Air  Force  cost  something  like  $75  per  instruc¬ 
tion  to  develop;  however,  the  maintenance*  of  the  software 
had  costs  up  to  $4000  per  instruction  [ Eef .  8]. 

The  trend  projected  through  1985  is  for  software  costs 
to  continue  to  rise  [Ref.  9].  In  part,  this  is  due  to  an 
increase  in  size  and  complexity  of  projects  and  an  overall 
increase  in  the  rate  of  technological  change.  The  industry 
is  currently  pouring  R&D  money  into  exploration  of  auto¬ 
mated  methods.  Some  progress  has  been  made  in  this  area; 
however  in  the  author's  opinion,  it  will  be  some  time  before 
wide  spread  use. 


PROBLEM: 

Schedule  slippage 


♦Maintenance  includes  all  costs  after  the  initial  devel¬ 
opment  effort  associated  with  keeping  the  software  m  opera¬ 
tion  (including  revisions/upgrades)  . 
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Schedule  slippage  results  for  a  number  of  reasons.  Nota¬ 
ble  among  them  is  personnel  related  problems.  Shill  levels 
among  programmers  vary  greatly,  also  the  amount  of  time  nec- 
cessary  to  program  in  different  languages  varies.  These  fac¬ 
tors  together  with  the  degree  of  complexity  of  the  system 
required,  must  be  considered  by  the  project  manager  in  malt¬ 
ing  the  schedule  estimate.  Most  often  a  project  manager 
inherits  a  project  for  which  these  estimates  have  been  made 
prior  to  the  assignment  of  the  project  team  and  the  project 
manager  will  have  to  make  adjustments  and  recommednations  to 
deal  with  inappropriate  estimates. 

Project  managers  must  rid  themselves  of  the  idea  that  if 
they  get  behind  schedule,  adding  more  programming  staff  will 
solve  their  problem.  3n  the  contrary,  in  many  instances  it 
will  no  doubt  have  quite  the  opposite  affect  That  is,  the 
new  staff  will  have  to  be  brought  up  to  speed  and  this 
entails  pulling  experienced  programmers  off  the  job  for  this 
purpose,  resulting  in  even  greater  delays.  Brooks'  Law 
states:  "Adding  manpower  to  a  late  software  project  makes  it 
later  "  [  Hef .  10  ]. 

It  is  obvious  that  the  preceding  problems  are  not  inde¬ 
pendent,  and  that  difficulty  in  any  one  of  them  has  a  signi¬ 
ficant  impact  on  each  of  the  others. 
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In  summary,  the  difference  between  software  project 
successes  and  failures  has  aost  often  been  traced  to  good  or 
poor  practices  in  software  aanageaent.  These  problems  can 
be  divided  into  the  following  three  aajor  areas: 

POOB  PLANNING :  Generally  this  leads  to  large  amounts  of 
wasted  effort  and  idle  time  because  of  tasks  being  unne- 
ceassarily  performed,  overdone,  poorly  synchronized,  or 
poorly  interfaced. 

POOB  CONTBOL:  A  plan  is  useless  when  it  is  not  kept  up  to 
date  and  used  to  aanage  the  project.  Also,  the  selection 
of  the  correct  control  method  for  the  organization  is  cri¬ 
tical  for  success. 

POOB  BESOOHCE  ESTIMATION:  without  a  firm  idea  of  how  much 
time  and  effort  a  task  should  take,  the  manager  is  in  a 
poor  position  to  exercise  control.  Improper  assignment  of 
personnel  to  tasks  can  cause  cost  and  schedule  overruns. 

In  short,  the  key  to  project  success  lies  with  the  man¬ 
agement  team  and  the  efforts  they  make  to  establish  project 
control.  In  the  following  chapters,  the  author  will  examine 
FNOC's  project  management  needs  in  relation  to  these  and 
other  considerations. 
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III.  OVERVIEW  OF  FNOC  OPERATIONS 

FNOC  provides  a  wide  spectrum  of  numerical  ,  meterologi- 
cal,  and  oceanographic  products  to  worldwide  users  on  a 
real-time  basis.  A  multi-mainframe  computer  center  is  used 
to  execute  report  processing,  analysis,  prediction,  display 
and  research  jobs  as  a  major  part  of  the  command's  mission. 

A  standard  sequence  of  scheduled  jobs  known  as  the  opera¬ 
tional  run  (OPS  RUM)  is  processed  every  12  hours  to  accom¬ 
plish  a  complete  global  me terological  and  oceanographic 
analysis  and  prognosis  cycle.  A  database  of  current  environ¬ 
mental  observations  and  a  complete  set  of  climatological 
information  is  used.  The  goal  of  the  OPS  RUN  being  to  pro¬ 
vide  analysis  and  forecast  fields  and  data  for  transmission 
to  00D  facilities  and  users  as  soon  as  possible  after  the 
receipt  of  raw  observations. 

PNOC  is  an  integral  part  of  the  naval  oceanographic  and 
meterological  support  system.  See  Figure  2.  Environmental, 
meterological,  oceanographic  observations  (raw  data)  and 
requests  for  services  come  into  FNOC,  the  primary  production 
facility,  via  the  Automated  Weather  Network  (AWN),  AUTODIN, 
A9SAT,  or  the  suitland  data  line.  The  raw  data  is  quality 
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checked,  sorted,  and  edited  by  computer  programs,  after 
which  the  analysis,  prognosis,  and  applications  programs  are 
run  and  the  output  processed  and  placed  in  the  integrated 
database. 

&  sophisticated  series  of  prediction  programs  generate 
forecast  variables  such  as  wind,  temperature,  pressure, 
moisture,  and  sea  heights,  to  provide  the  fleet  with  a  four 
dimensional  measure  of  the  air-ocean  environment  in  which 
they  operate.  These  products  are  distributed  to  the  four 
weather  centrals  (Pearl, Guam  Norfolk,  and  Rota)  via  the 
Naval  Environmental  Data  Network  (NEON)  and  the  Naval  Envi¬ 
ronmental  Display  System  (NEDS) .  The  weather  centrals  tailor 
these  products  before  disseminating  them  to  end  users.  In 
some  cases  PNOC  provides  environmental  products  directly  to 
the  end  users. 

The  products  produced  by  FNOC  are  of  two  basic  types; 
routine/  scheduled  or  tailored.  Special  requests  for  tai¬ 
lored  products  are  based  on  changing  fleet  or  other  opera¬ 
tional  committments.  These  products  are  transmitted  via  the 
telecommunications  system.  Figure  3  is  a  listing  of  some  of 
the  products  currently  provided  by  FNOC.  A  primary  emphasis 
in  oceanographic  modeling  is  support  of  antisubmarine  war¬ 
fare  forces.  FNOC  provides  fleet  units  with  expected 
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detection  ranges  for  each  of  their  acoustic  sensor  systems, 
no  matter  where  they  are.  Currently,  satelite  processing  is 
becoming  the  focus  of  attention,  as  a  means  of  providing  a 
more  accurate  database. 

To  provide  all  these  services;  FNOC  maintains  twenty- 
four  hour  computer  center  operations,  manned  by  military 
and  civilian  personnel.  There  is  considerable  development  of 
advanced  techniques  and  capabilities  in  data  processing, 
ocean  and  atmospheric  analysis,  prediction,  display,  appli¬ 
cations  and  communications.  There  is  continual  planning  and 
implementation  of  computer  systems  upgrades. 

The  project  approach  is  frequently  used  to  meet  new  and 
changing  requirements  at  FNOC;  hence,  there  is  a  sound  rea¬ 
son  for  seeking  to  optimize  the  project  management  proce¬ 
dures  and  controls. 
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FNOC  PRODUCTS 


BOOTHS 

area  forecasts 
wind  and  sea  warnings 
terminal  and  local  forecasts 
oceanographic  outJooks 
acoustic  predictions 

analysis  and  prognosis  for  atmosphere  and  ocean 
TIILOBED 

optiaua  track  ship  routes  (OTSB) 

enroute  ship  weather  forecasts  (HE&X) 

refractive  effects 

ballistic  wind  and  densities 

anphibious  forecasts 

environmental  briefings 

cliaatological  studies 

optimum  path  aircraft  routing  (OPhRS) 

acoustic  predictions 

search  and  rescue  (S&R) 

Figure  3 
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IV.  NATURE  OF  THE  PROBLEM 


i 


A.  PAST  HANDLING  OP  PROJECTS 

In  late  1976  FNOC  adopted  a  computerized  descriptive 
list  of  projects.  This  listing  was  originally  developed  for 
use  exclusively  by  the  Data  Integration  Department.  This 
action  constituted  the  first  step  in  the  development  of  a 
MIS  to  assist  in  project  control.  This  list  was  only  a 
beginning  and  fell  far  short  of  fullfilling  the  needs  of  the 
command.  Due  to  other  commitments  and  limited  resources, 
little  progress  was  made  in  improving  the  system.  There 
were  several  serious  problems  with  the  system;  the  report 
format  was  not  well  defined,  file  updates  were  irregular  and 
incomplete,  and  milestone  dates  were  passed  without  comment 
or  explanation.  A  serious  problem  worth  discussing,  was  the 
fact  that  the  system  lacked  middle  management  support.  The 
primary  reasons  given  for  dissatisfaction  with  this  MIS 
were  that  it  was  a  cumbersome  and  ill-defined  system  and 
that  it  provided  very  little,  if  any,  benefits  to  the  middle 
manager. 

The  MIS  received  considerable  command  attention  between 
1976  and  1977;  however,  commitment  of  personnel  resources  to 
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solve  its  many  problems  was  lacking.  After  this  period  the 
MIS  received  only  ocasional  command  level  emphasis  and  by 
mid  1979  there  was  considerably  less  insistence  on  keeping 
the  information  updated.  By  1980  the  commanding  officer  had 
taken  the  MIS  out  of  operation  completely. 

It  would  seem  that,  by  all  development  standards,  this 
MIS  was  doomed  from  the  start.  Installing  an  information 
system  is  a  complex  job.  It  involves  an  examination  of  the 
entire  structure  of  the  organization  and  the  information 
flow.  Clearly,  this  was  not  done  in  this  case.  The  need 
exists  for  more  planning  and  some  definite  attention  to  the 
organizational  problems. 

B.  CURRENT  HANDLING  OP  PROJECTS 

Currently  there  is  no  automated  MIS,  neither  are  there 
any  well-defined  procedures  for  project  control  and 
reporting. 

Several  manual  reporting/tracking  mechanisms  have  been 
tried  recently,  including  the  completion  of  the  form  in 
Pigure  4.  These  represent  major  milestones/tasks  to  be 
accomplished  during  the  periods  indicated.  These  tasks  are 
listed  by  department,  staff  position,  and  major  projects. 
Although  only  a  crude  mechanism;  it  does  force  involved  per¬ 
sonnel  to  give  some  thought  to  their  own  priorities  in 
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relation  to  the  coaaand's  priorities.  The  problem  is,  all 
personnel  involved  do  not  contribute;  therefore  the  inforaa- 
tion  is  not  coaplete. 

&  second  aechanisa  currently  in  use  is  the  Projects  and 
Plans  Suaaary,  Figure  5,  initiated  during  the  spring  of 
1981.  The  Plans  and  Prograas  Officer  has  identified  8  gen¬ 
eral  project  areas  based  on  function;  within  these  areas 
there  aay  be  aany  projects.  This  suaaary  identifies  priaary 
resources  involved  and  scheduled  events,  activities,  and 
ailestones  for  the  current  fiscal  year  and  beyond.  It  is 
strictly  a  aanual  effort  and  the  initial  suaaary  took  three 
days  of  concentrated  effort  to  produce  (this  tiae  does  not 
include  its  planning  tiae) .  These  dates  are  aonitored  using 
strictly  aanual  aethods  which  requires  constant  vigilance 
and  attention  to  detail.  It  is  highly  likely  that  when  the 
current  Plans  and  Prograas  Officer  leaves  FNOC  (in  the  fall 
of  1981)  this  suaaary  will  cease  to  exist. 

Reporting  of  developaent  projects  is  handled  via  the 
Hork  Unit  Package  which  is  subaitted  twice  a  year  and 
updated  only  for  aajor  changes.  This  report  is  produced  on 
a  word  processor;  however  no  data  aanipulation  is  done. 

This  is  due  in  part  to  references  24  and  25,  which 
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specifically  prohibit  use  of  word  processing  eguipaent  for 
data  aanipulation  without  prior  approval. 

C.  FNOC  PROJECT  ENVIRONMENT 

FNOC  utilizes  a  matrix  organization  for  project  aanage- 
■ent.  Figure  6  represents  the  general  structure  of  this 
organization,  while  Figure  7  depicts  FNOC's  operational 
organization.  Matrix  aanageaent  is  based  on  the  concept  of 
pulling  together  technical  and  managerial  talent  into  a  team 
to  operate  without  the  liaits  of  discipline  or  organiza¬ 
tional  lines.  Matrix  relationships  are  far  aore  complex 
than  traditional  functional  relationships  in  which  the  rela¬ 
tionships  are  predominantly  vertical  with  few,  if  any, 
cross-functional  aspects.  Each  major  group  or  department  is 
primarily  concerned  with  its  own  goals.  The  matrix  organiza¬ 
tion  changes  these  traditional  patterns  by  creating  new  ver¬ 
tical,  horizontal,  and  diagonal  relationships  among  its 
members.  Communication  becomes  far  aore  critical  in  a 
matrix  organization;  thus,  tight  project  control  and 
reporting  becomes  increasingly  crucial. 

The  department  head's  goal  orientation  aust  also  change 
due  to  the  aatrix  organization,  in  that  they  aust  be  con¬ 
cerned  with  project  goals  in  addition  to  their  functional 
goals.  [Ref.  11]  In  a  aatrix  organization,  the  functional 
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specialist  is  placed  in  the  difficult  situation  of  taking 
direction  fro*  two  managers;  therefore,  if  there  are  not 
well  defined  channels  of  authority,  there  is  potential  for 
considerable  conflict.  Irregardless  of  this,  due  to  the 
nature  of  the  project  environment,  matrix  management  appears 
to  be  the  proper  choice.  The  built-in  conflict,  if  handled 
properly,  tends  to  enhance  initiative  among  the  participants 
as  they  compete  for  the  limited  resources. 

Matrix  management  is  indeed  difficult;  however,  it  faci¬ 
litates  the  coordination  and  integration  of  many  project 
activities,  and  provides  the  flexibility  required  in  a  com¬ 
plex  multifunction  environment  such  as  FNOC.* 

Two  staff  positions  were  established  to  aid  in  project 
planning  and  control.  The  PLans  and  Programs  Officer,  res¬ 
ponsible  primarily  for  long  range  planning  and  budgeting, 
and  the  Development  Coordinator,  responsible  for  coordinat¬ 
ing  BSD  activities  under  work  unit  funding. 


*?or  additional  reading  on  matrix  management  consult 
reference  11. 
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FNOC  PRIORITIES 


FNOC  PROJECT  MATRIX  ORGANIZATION 


CO  Commanding  Officer 
PM  Project  Manager 
DH  Department  Head 
FS  Functional  Specialist 


FIGURE  6 
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FNOC  OPERATIONAL  ORGANIZATION 


FIGURE  7 


V. 


This  study  focused  on  the  identification  of  user 
requirements  for  PICS. 

A.  IDENTIFICATION  OF  THE  PROBLEM 

The  initial  concentration  of  this  thesis  was  to  formu¬ 
late  and  describe  a  problem  statement  for  project  manage¬ 
ment  at  FNOC.  Further  discussion  then  focused  on  the 
various  causes  that  had  combined  to  produce  the  problem.  The 
discussion  also  presented  details  about  the  past  and  current 
project  management  procedures  .  Having  made  a  largely  sub¬ 
jective  determination  of  the  problem,  the  next  step 
involved  an  analysis  of  the  user’s  needs. 

B.  AN ALISIS  OF  OSEB’S  NEEDS 

Twelve  key  PNOC  personnel  were  selected  on  the  basis  of 
their  senior  management  positions  at  FNOC  or  their  expertise 
and  longevity  in  the  project  management  environment.  Indivi- 
dual  PERSONAL  INTERVIEWS  were  conducted  with  each  of  the 
tweleve  individuals.  The  question  posed  was;  what  informa¬ 
tion  requirements  and/or  capabilities  would  you  like  to  see 
in  a  project  management  and  control  system  at  FNOC  (either 
automated  or  manual).  Individuals  responses  were  not 
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revealed  to  other  interviewees  and  the  interviewer  limited 


her  input,  so  as  not  to  impose  her  views  on  those  being 
interviewed. 

Responses  from  interviews  were  consolidated  in  an  uned¬ 
ited  CHECKLIST  form  and  distributed  to  all  FNOC  personnel 
directly  involved  in  project  management  at  some  level.  Those 
involved  in  the  personal  interviews  were  also  asked  to  com¬ 
plete  the  checklist  inorder  to  validate  the  information  and 
assure  that  the  interviewer's  interpretation  of  their  origi¬ 
nal  responses  was  correct. 

C.  ANAL? SIS  OF  REQUIREMENTS 

Check  list  responses  were  classified  as  to  management 
level  (CO/XO/  DEPT  HEAD/PRINCIPAL  INVESTIGATOR/PROJECT 
MANAGER)  and  analized.  Items  that  were  not  felt  to  be 
necessary  were  deleted  and  a  comprehensive  list  of  require¬ 
ments  was  identified  as  the  minimum  necessary  for  a  Project 
Information  and  Control  System  (PICS). 

D.  REVIEW  OF  SOFTWARE  PACKAGES 

The  criteria  to  be  satisfied  by  a  project  managment 
software  package  was  outlined  and  a  survey  of  available 
software  packages  was  made.  Each  software  package  was 
compared  to  the  established  criteria  to  select  the  most 
appropriate  package/packages. 
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This  preliminary  screening  was  based  on  the  established 
general  system  requirements.  The  intention  was  to  reduce  the 
number  of  packages  being  considered  to  those  that  appeared 
most  likeley  to  meet  the  needs  of  the  organization. 

E.  PRESENTATION  OF  ALTERNATIVES 

A  variety  of  feasible  alteratives  were  identified  in  an 
attempt  to  cover  the  entire  spectrum  of  possibilities. 

Their  advantages  and  disadvantages  were  examined  and  dis¬ 
cussed  to  give  the  executive  a  view  of  their  relative  value. 
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VI. 


A.  OBJECriVES  OP  THE  PROJECT  INFORMATION  AND  CONTROL  SYSTEM 
The  overriding  objective  of  most  organizations  in  imple¬ 
menting  an  automated  information  system,  is  to  increase  the 
overall  effectiveness  of  the  organization  involved.  In  the 
private  sector,  this  translates  into  increased  profits.  In 
the  public  sector,  it  is  not  as  easily  measured. 

In  order  to  define  more  specific  objectives  for  the 
automated  system,  the  author  conducted  personnel  interviews 
with  FNOT  personnel.  These  interviews,  together  ;ith  the 
author's  personal  experience,  were  then  used  to  describe  the 
following  overall  objectives  for  an  automated  project  man¬ 
agement  and  control  system. 

1.  Must  require  minimal  inputs  to  the  system,  that  is, 
once  the  initial  system  has  been  established,  it  should  be 
no  more  cumbersome  to  maintain  then  current  record 
keeping. 

2.  Must  deliver  information  to  the  appropriate  manager 
when  it  is  needed,  so  that  situations  requiring  immediate 
decisions  can  be  controlled,  and  situations  that  are  not 
pressing  can  be  deffered,  but  not  to  the  point  of  loss  of 
control. 
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3.  Hast  provide  for  siaultaneous  horizontal  and  vertical 
dissemination  of  necessary  information,  so  that  top  level 
management  and  every  operating  department,  will  be  ade¬ 
quately  informed.  la  particular,  it  is  important  that  the 
vertical  dissemination  of  information  follow  only  the 
necessary  path.  Furthermore,  information  sent  in  a  ver¬ 
tical  direction  should  be  directed  only  as  low/high  as 
required  to  make  or  retract  a  decision. 

4.  Must  reduce  reams  of  information  to  meaningful  facts 
for  management  to  use  in  planning  the  future  operations  of 
the  organization. 

3.  USER  INFORMATION  REQUIREMENTS 

One  of  the  first  steps  in  developing  or  obtaining  a 
software  system,  is  to  define  the  user's  requirements.  This 
is  far  more  involved  than  it  sounds.  After  almost  twenty 
years  of  attention,  it  is  still  often  the  case,  that  compu¬ 
ter  based  application  systems  are  developed  behind  schedule, 
over  cost,  don^t  do  as  much  as  premised,  and  don't  satisfy 
the  user  needs.  At  the  heart  of  this  problem,  is  the  fact 
that,  often  the  requirements  for  these  applications  were 
never  stated  accurately  or  completely  in  the  first  place. 

The  fact  that  one  may  never  reach  perfection  in  this  area 
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should  not  prevent  an  all  out  effort  to  identify  require¬ 
aents  as  completely  as  possible. 

The  importance  to  project  success  of  getting  these 
requirements  right,  can  not  be  over  stated.  If  the  require¬ 
ments  are  not  complete  or  correct,  the  system  may  not  be 
usable.  If  the  system  is  salvagable,  the  cost  incurred  in 
correcting  the  system  may  be  excessive  and  the  additional 
tiae  required,  could  be  tiae  better  spent  elsewhere.  There 
is  also  the  possibility  that  the  organizational  effective¬ 
ness  will  be  decreased,  due  to  either  not  having  a  workable 
system,  or  having  one  that  only  partially  meets  their  needs. 

Certainly  our  record  of  customer  satisfaction  is  not 
good.  For  that  reason,  we  must  be  aware  of  the  problems  and 
recognize  that  a  substantial  number  of  errors  will  exist  in 
most  requirements  statements,  unless  specific  action  is 
taken  to  identify  and  remove  them  [Ref.  12]. 

There  are  three  basic  approaches  to  information  require¬ 
ments  analysis  [Ref.  13]. 

DIRECT  ANALYSIS,  which  involves  interaction  with  the  user 
to  identify  decision  processes  and  information  elements. 
IVDIRECT  ANALYSIS  is  the  evaluation  of  data  utilization, 
such  as  observing  people  or  reports,  in  order  to  infer 
information  requireaents. 
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HTBBID  ANALYSIS,  which  is  a  combination  of  direct  and 
indirect. 

The  author  utilized  the  hybrid  analysis  approach, 
together  with  her  personal  experience.  It  must  be  emphasized 
however;  that  this  is  simply  a  preliminary  analysis  of  user 
requirements,  and  that  a  more  extensive  analysis  should  be 
undertaken  if  the  decision  is  made  to  pursue  this  idea 
further. 

Information  for  data  itams  was  collected  from  inter¬ 
views,  check  list  responses,  and  the  author's  experience.  It 
was  not  felt  necessary  to  include  every  data  item  from  each 
source  of  information.  The  amount  of  effort  needed  to  obtain 
and  enter  some  items  of  data,  coupled  with  the  increased 
storage,  capacity  necessary,  and  subsequent  longer  retrieval 
times,  far  overshadowed  the  possible  benefit  that  could  be 
gained  from  having  that  information  on  line. 

The  author's  value  judgements  were  used  to  define  a  com¬ 
prehensive  requirements  list  that  would  be  useful  without 
being  overly  demanding  on  resources.  Future  evaluations  of 
update  and  usage  rates  of  these  data  items  should  be  made 
once  a  system  is  in  use,  to  reduce  the  size  of  the  database 
by  eliminating  unused  items. 
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The  following  are  deemed  minima  1  information 


requirements  for  an  automated  project  management  and  control 
system. 

*  A  means  of  establishing  and  tracking  milestones,  actual 
versus  planned. 

*  A  method  to  provide  information  on  available  resources, 
personnel,  monetary,  and  computer,  and  their  utilization 
and/or  allocation. 

*  A  means  of  indicating  priority  of  projects. 

*  A  means  of  establishing  and  promulgating  lines  of 
authority  and  responsibility. 

*  The  ability  to  include  narrative  comments. 

*  A  means  of  indicating  time/scheduling  information. 

*  A  means  tg  break  the  prgject  up  into  tasks  and  subtasks 
for  tracking  and  reporting. 

Reference  14  and  appendix  A  ,  contain  more  detailed 
requirements  for  recommended  data  elements. 

It  is  recognized  that  these  requirements  differ  with 
each  level  of  management  as  does  the  degree  of  detail  of  the 
information.  Anthony,  [Bef.15]  in  his  framework  for  plan¬ 
ning  and  control,  focuses  on  three  categories  of  decisions 
which  can  be  translated  to  the  levels  of  project  management 
at  PHOC.  They  are: 

STB&TBSIC  PLAHHIHG:  which  is  equivalent  to  the  type  of 

decisions  made  at  the  staff  level  (CO, XO, staff 

,  *CRAS  (Computer  Resources  Accounting  System)  will  pro¬ 
vide  information  related  to  EDP  usage. 
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assistants) .  They  require  only  summary  level  information 
rather  than  more  detailed  reports. 

NANAGERZAL  CONTROL:  the  key  concern  here  is  that 
resources  are  obtained  and  used  effectively  and  effi¬ 
ciently  to  accomplish  the  defined  objectives.  In  FNOC's 
project  environment  this  can  be  equated  to  the  principal 
investigator  and  department  head..  They  require  details  of 
resource  utilization  and  milestone  information. 

OPERATIONAL  CONTROL:  at  this  level  of  decision  the  empha¬ 
sis  is  on  assuring  that  tasks  are  carried  out  effectively 
and  efficiently.  This  equates  to  the  project  manager 
level  at  PNOC.  The  project  manager  is  concerned  with  the 
day  to  day  operations. 

In  order  to  provide  the  flexibility  necessary  to  meet 
the  diverse  needs  of  the  various  users,  this  information 
should  be  accessable  according  to  a  number  of  retrieval 
criteria,  such  as: 

*  miletones  exceeded 

*  upcomming  milestones 

*  funding  source 

*  responsible  principle  investigator , department, division 

*  name  of  project  manager 

*  system  relationship  (ie.  PEPS 0,  CCS, NEDS) 

*  priority 

*  estimated  cost 

*  duration  of  projects 
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*  classification  of  projects  (ie.  development,  operational, 
or  maintenance) 

*  resource  allocation  exceeded 

*  noncompliance  with  established  update  schedule. 

C.  GENERAL  SYSTEBS  CAPABILITIES 

Aside  froa  the  inforaation  requirements  listed  in  the 
previous  section,  there  are  a  number  of  desirable  capabili¬ 
ties  the  system  should  have.  They  include  the  following, 
which  are  listed  according  to  relative-  importance: 


*  The  ability  to  run  on  equipment  currently  available  to 
FNOC. 


* 


?uiring  little  or  no 
project  staff. 


*  At  lea?t  3  levels  of  reporting;  summary,  detailed  and 
exception.  To  assure  that  only  that  information  of 
interest  to  a  particular  management  level  may  be  pre¬ 
sented.  Ackoff,  [Ref.  16]  emphasizes  that  contrary  to 
popular  belief,  managers  suffer  most  from  inforaation 
overload  rather  than  lack  of  information. 


*  A  means  to  control  who  is  authorized  to  update/modify 
project  information  m  the  file. 

*  Backup/recovery  procedures 

*  Flexibility  in  report  formats  to  allow  individual  manag¬ 
ers  to  get  the  information  they  require  in  a  form  that 
is  most  usefull  to  theaf  it  is  critical  that  middle 
managers  receive  some  direct  tangible  benefit  from  the 
project  management  and  control  system  if  they  are  to 
support  it. 

*  Specific  definitions  (ie.  pro ject, task,  sub¬ 
task,  milestdone)  so  that  all  reporting  is  done  in 
regards  to  a  common  basis. 

*  Interactive  capability  option 

*  ability  to  support  multiple  users  in  the  interactive 
mode. 
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VII.  SOFTWARE  PACKAGE  REVIEW 


Commercially  available  software  packages  are  becoming  a 
major  market  factor  in  the  data  processing  industry.  They 
have  aany  advantages  over  independently  developed  applica¬ 
tions.  Host  packages  are  well  designed  and  documented  and  if 
the  package  has  been  on  the  market  for  some  time,  there  is  a 
good  chance  that  most  of  the  serious  bugs  have  been  elimi¬ 
nated.  Software  packages  permit  the  installation  of  a  new 
system  for  relatively  less  cost  than  that  of  in-house  devel¬ 
opment  due  to  the  fact  that  the  cost  can  be  spread  over  many 
customers.  There  is  little  or  no  risk  of  cast  or  schedule 
overrun  usually  associated  with  software  development 
efforts.  This  allows  management  to  establish  dependable 
schedules  for  implementation  and  accurate  budget  plans. 

The  purchase  of  a  software  package  also  allows  the 
organization  to  utilize  the  professional  talents  of  their 
programmers  and  systems  analysts  in  the  development  of  sys¬ 
tems  unique  to  their  organization,  rather  than  in  redevelop¬ 
ing  systems  that  have  been  developed  by  many  before  them. 
Additionally,  if  an  organization  deals  with  a  reliable  ven¬ 
dor,  they  minimize  the  risk  associated  with  maintaining  the 
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system.  The  organization's  options  are  broadened  in  that  if 
they  do  not  have  the  shills  or  personnel  available  to  main¬ 
tain  the  systea,  they  may  call  upon  the  assistance  of  the 
vendor  (at  the  established  rate). 

There  are  a  great  number  of  software  packages  available 
that  are  marketed  as  aids  to  project  management  and  control. 
These  packages  vary  greatly  in  their  scope,  some  are 
designed  to  assist  in  the  planning  and  tracking  of  only  one 
project,  others  will  handle  any  number  of  projects  and  pro¬ 
vide  a  great  deal  of  flexibility  within  the  organization. 

The  problem  is  that  there  are  very  few  written  in  FORTRAN, 
the  preferred  language  for  implementation  at  FNOC. 

The  author  found  3  packages  that  were  available  in 
P3RTRAN.  All  3  were  eliminated  from  consideration  because  it 
was  felt  that  they  would  not  meet  the  minimum  requirements. 
PAC  I  is  marketed  by  International  Sysytems  Inc.  (ISI) , 
King  of  Prussia,  Pa.  This  package  is  designed  to  track 
only  1  projeqt  at  a  time  and  therefore  was  eliminated. 
P.D.P.-B.D.H.S.  is  available  from  Control  Data  Corpora¬ 
tion.  This  package  was  eliminated  due  to  its  strictly 
financial  orientation. 

OSCAR,  marketed  by  On-Line  Systems,  Pittsburgh,  PA.,  is 
available  only  in  the  time  sharing  mode. 
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Pailing  to  find  a  suitable  POBTHAN  software  package,  the 
author  chose  to  continue  the  search  under  the  assumption 
that  it  was  still  feasible  to  purchase  a  software  package 
and  lease  a  COBOL  coapilar  for  less  cost  than  in-house 
development.  This  idea  will  be  discussed  further  in  chapter  8. 

An  examination  of  the  trends  and  the  state  of  the  art  in 
computer  programming  and  software  package  applications, 
along  with  a  preliminary  analysis  of  the  information 
requirements  of  a  project  information  and  control  system 
(PICS)  at  FNOC,  provided  a  background  for  establishing  the 
criteria  for  selecting  a  computer  software  package.  Woo¬ 
dridge,  [aef.  17]  suggested  4  categories  for  software  selec¬ 
tion  criteria.  These  criteria  address  requirements  in  the 
area  of  features,  technical  and  operational  environment, 
implementation,  and  price  of  the  package.  The  author  used 
these  4  categories  in  the  evaluation  of  the  available 
packages. 

A.  EVALUATION  C  SHERI  A  USED 

i*  esaiaiss 

The  package  should  contain  as  many  of  the  features 
described  in  chapter  6 ,  section  B  as  possible. 
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2.  Technical  And  Operational 


It  aust  be  possible  to  operate  the  package  in  the 
present  environment.  &  thorough  analysis  of  the  technical 
and  operational  features  of  the  candidate  packages  as  they 
relate  to  the  intended  environment  will  assist  in  an  appro¬ 
priate  package  selection. 

a.  Hardware  Configuration 

The  package  oust  be  capable  of  operating  on  the 
equipment  currently  available.  This  includes  the  available 
core  memory  as  veil  as  peripheral  equipment  (ie.  card 
reader,  plotter,  printer,  etc.)  Mainframes  currently  at 
PNOC  available  include  3  CDC  6500s,  a  CYBER  175,  a  CYBER 
203,  a  CYBER  170/720,  and  2  PDP  11s. 

b.  Higher  Level  Language 

A  higher  level  language  such  as  FORTRAN  or  COBOL 
must  have  been  used  to  write  the  programs. 

c.  Operating  System 

The  package  should  be  capable  of  operating  under 
the  NOS/BE  operating  system. 

d.  Ease  Of  Use 

The  package  must  require  minimal  manual  inputs. 
In  other  words;  it  should  be  no  more  cumbersome  than  current 
manual  reporting  ,  record  keeping,  and  control  mechanisms  at 
PNOC. 
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e.  Flexibility 

incorporate  selected  current  procedures  and 
reporting  formats. 

3.  Implementation  4nd  Maitenance 

Two  necessary  requirements  which  ensure  that  the 
package  can  be  iapleaented  when  needed  and  aaintained  with 
ainiaal  effort  are: 

a.  Immediate  Availability 

package  must  be  available  for  immediate  delivery 
and  implementation,  not  in  an  under  development  status. 

b.  Supplier's  Reputation  And  Business  Integrity 

The  supplier  must  be  responsive  to  it  user's 

problems.  They  must  be  a  well  established  company  with  a 
stable  professional  staff. 

c.  Training  And  Documentation 

Documentation  should  cover  the  system,  opera¬ 
tions,  users,  data  preparation, and  programming.  It  should 
allow  for  ease  of  use  and  maintenance.  Training  should  be 
availablae  and  a  training  manual  available  for  inspection. 

4.  ?rice 

Ideally,  the  package  should  be  available  to  the 
user  with  no  additional  start-up  costs. 

Software  directories  and  professional  publications  were 
searched  to  identify  feasible  candidate  packages. 
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Many  were  eliminated  immediately  because  they  were  not  capa¬ 
ble  of  running  on  CDC  equipment.  The  following  packages 
were  thought  to  possess  most  of  the  desired  capabilities  and 
warrant  closer  review  and  examination  by  FNOC  professionals. 

B.  INTERNATIONAL  SYSTEMS'  PAC  II  [Ref.  18] 

1 .  General  Information 

International  systems  Inc.  (ISI) ,  King  of  Prussia, 
PA,  has  developed  a  sotware  package  for  project  management 
called  PAC  II.  ISI  specializes  in  automated  project  manage¬ 
ment  systems.  Pac  II  performs  numerous  and  varied  functions 
as  depicted  in  Pigure  8. 

Pac  II  is  a  totally  data  base  oriented  system,  con¬ 
sisting  of  2  main  modules.  The  planning  module  uses  a  sin¬ 
gle,  easy  to  use  input  sheet.  This  module  assists  the  user 
in  directing  and  scheduling  project  resources.  It  supports 
a  simulator  capability  with  critical  path  ident ificiation, 
resource  loading,  and  inter-project  dependencies.  Activi¬ 
ties  can  be  assigned  to  resources  by  skill,  as  well  as  by 
specific  resource  identification.  In  fact,  PAC  II  is  capable 
of  making  proficiency  level  distinctions. 

The  management  module  accumulates  project  progress 
information  and  makes  available  multi-level  status,  cost, 
and  history  information.  A  single  turnaround  document, 
which  is  designed  by  the  user,  feeds  in  the  only  information 
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PAC  II  FUNCTIONS  j 

I 

♦budgeting 

♦resource  tracking 

♦planning 

♦Progress  reporting 

♦project  simulation 

♦automatic  audit  trail 

♦critical  path  analysis 

♦status  accounting 

♦scheduling 

♦project  monitoring 

♦modelling 

♦cost  accounting 

♦skill  scheduling 

♦statistical  analysis 

♦on  line/real  time 

♦graphics 

Figure 

8 

necessary  to  report  progress.  The  outstanding  feature  of 
this  nodule  is  its  ability  to  alert  management  early  when 
problems  occur.  The  user  sets  tolerance  levels  and  the 
updated  data  base  is  constantly  monitored.  Should  any  of 
these  limitations  be  broken,  PAC  II  automatically  alerts 
management  and  produces  detailed  reports  for  analysis  and 
corrective  action,  (ie.  projects  more  than  x  months  late  or 
cost  overruns  greater  than  x  percent)  This  is  a  particularly 
desirable  feature.  Project  managers  are  understandably  very 
reluctant  to  admit  their  project  is  behind  schedule.  This 
automatic  reporting  facility  alerts  upper  management  of  this 
type  of  problem. 
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Although  not  explicitly  termed  milestones,  the  same 
function  can  be  performed  by  defining  what  the  PAC  II  sys¬ 
tem  refers  to  as  "EVENTS”.  The  PAC  II  system  can  be  used 
to  plan  a  single  project  or  any  combination  of  projects.  Any 
number  of  activities  or  tasks  with  dependencies  across  pro¬ 
ject  lines. 

PAC  II  offers  a  variety  of  input  methods:  computer 
generated  turnaround  document,  manual  input  forms,  punched 
cards,  terminal  entry,  or  OCB.  Table  entries  are  used  for 
those  items  of  information  that  are  placed  on  the  file  once 
only;  but  are  used  constantly  (ie.  skill  codes,  holiday 
schedule)  .  Use  of  table  entries  can  save  the  user  many 
repetitive  entries  and  provides  for  ease  of  maintenance  and 
modification . 

ISI  offers  a  seperate  add  on  option,  the  PAC  II 
Beport  Writer,  a  facility  for  accessing  the  data  base  and 
producing  reports  that  have  not  already  been  programmed  into 
the  system.  This  facility  allows  the  user  to  request 
reports  in  a  format  they  specify.  Inputs  are  made  via  sim¬ 
ple  English  language  statements.  ISI  also  offers  an  inter¬ 
active  package  which  provides  a  terminal  data  entry  and 
planning  capability  and  a  graphics  package  which  offers 
users  2  different  options:  plotter  or  printer.  These 
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optional  software  packages  as  well  as  the  Report  Writer 
option,  may  be  purchased  with  the  basic  P AC  II  systen  or  be 
added  on  at  a  later  date  if  desired. 

2.  Cost  Information 

Prices  in  effect  as  of  the  writing  of  this  thesis 
are  as  follows: 


PiC  II  basic  system 
plus  1  time  installation 
total 

cost  to  purchase  after 
one  year* 

optional  software  available 
PAC  REPORT  WRITER 
plus  1  time  charge 
total  (1  year) 

PAC  INTERACTIVE 
plus  1  time  charge 
total  (t  year) 


bay  lease/purchase 

$26,000  $15,600/yr 

$2,  160 

$26,000  $17,760 

$13,568 


$4,000  $2, 400/yr 

$  330 

$2,730 

$10,000  $  6,000/yr 

$  830 

$6,830 


*70%  of  the  first  years  lease  payment  and  installation 
charge  will  be  applied  to  reduce  the  purchase  price. 
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Basic  package  price  includes: 


PAC  II  COBOL  source  programs  (on  tape) 

PAC  II  maintenance  and  enhancements  for  1  year 

pre  installation  meeting 

documentation 

*  implementation  guide  12) 

*  coordinators  case  study  (1) 

*  users  reference  manual  (2) 

*  project  leaders  guide  (2) 

*  input  forms 

*  user  reference  cards  (25) 

*  selection  of  turnaround  documents 

installation,  checkout,  classes  and  OJT. 


3.  Additional  Information 


PAC  II  is  currently  installed  on  CDC  equipment  in 


several  areas.  Contact  was  made  with  US.  Dee  Thorne  in  the 


data  processing  department  of  Reynolds  Electric  and  Engi¬ 


neering,  Las  Vegas,  Nevada  [8ef.  19].  This  company  was  cho¬ 


sen  because  it  not  only  has  a  PAC  II  package  installed  on 


CDC  equipment;  but  it  is  also  operating  under  the  NOS/BE 


operating  system.  This  organization  has  a  CDC  6400  and  a 


CYBER  74  operating  in  tandem.  Reynolds  is  the  prime  con¬ 


tractor  for  the  Nevada  Test  Site  and  as  such,  they  utilize 


PAC  II  in  a  variety  of  applications,  including  R&D  develop¬ 


ment. 


Ns.  Thorne  indicated  that  they  have  received  excel¬ 
lent  response  from  ISI  and  that  they  are  please  with  PAC  II. 
They  also  purchased  the  PAC  II  REPORT  WRITER  option;  but 
chose  to  develops  their  own  interactive  capability  in-house. 
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Ms.  Thorne  is  very  agreeable  to  further  consultation  with 
FNOC  staff. 

C.  NICHOLS*  N5500  [Ref.  20] 

1 .  General  Information 

In  1977  Nichols  and  company  of  Los  Angeles,  CA. , 
developed  a  project  planning  and  control  system,  currently 
marketed  as  N5500.  PERT  and  precedence  networking  enable 
the  Nichols  system  to  constantly  monitor  the  impact  of  slip¬ 
pages  and  plan  changes  on  in-process  projects.  Hhat-if 
simulation  capabilities  highlight  the  impact  that  proposed 
projects  and/or  changes  will  have  on  the  current  in-procoss 
work  load.  Critical  path  analysis  and  slack  time  indica¬ 
tions  provide  the  user  the  ability  to  optimize  schedules 
and  minimize  resource  waste. 

The  planning  process  starts  with  the  user's  defini¬ 
tion  of  the  organization's  planning  environment.  This  is 
accomplished  through  the  use  of  a  dictionary  mechanism. 

This  means  this  information  need  only  be  inputed  once,  the 
dictionary  is  maintained  seperately  from  the  rest  of  the 
data  which  makes  validation  and  modification  a  less  compli¬ 
cated  task.  The  use  of  the  dictionary  also  allows  the  sys¬ 
tem  to  be  adapted  to  any  life  cycle  methodology,  work 
breakdown  structure,  or  documentation  standards.  The  use  of 
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the  dictionary  mechanism  also  significantly  reduces  the 
redundant  entry  of  data.  This  means  a  tine  and  effort 
savings  to  the  user. 

The  Nichols  system,  like  the  PAC  II  systea,  has  an 
option  for  automatic  assignaent  of  resources  by  the  systea, 
which  can  be  valuable  to  the  planner.  Changes  to  projects 
can  be'  accoaplished  with  remarkable  ease.  Tasks  nay  be 
added,  changed,  or  deleted  at  any  tine,  and  the  impact  of 
any  change  will  automatically  be  shown  on  all  related  tasks 
and  projects.  Task  changes  only  require  that  a  project  num¬ 
ber,  task  number,  and  the  revised  data  be  entered. 

Project  control  is  accomplished  through  the  distri¬ 
bution  of  work  schedule  reports  use  to  publish  work  assign¬ 
ments.  Each  person  or  group  then  reports  back  the  work  done 
on  each  task  during  the  week,  the  work  remaining  to  be  done 
on  each  in-process  task  for  that  week,  and  any  comments  they 
wish  to  call  to  the  project  managers  attention. 

The  Nichols  system  has  a  mechanism  where-by  an  overt  error 
in  a  data  field  will  not  cause  the  system  to  stop  perform¬ 
ing.  The  systea  simply  makes  a  best  guess  and  executes  the 
program  regardless  of  the  number  or  severity  of  these 
errors.  Although  these  errors  are  flagged  and  continue  to 
be  flagged  until  corrected;  this  feature  should  be  closely 
examined  by  FNOC  analysts  to  determine  if  it  is  desirable. 
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The  Nichols  system  offers  20  report  foraats  as  part 
of  its  basic  systea.  These  reports  cover  6  major  groupings: 
administration,  project  planning  and  control,  resource  load 
and  distribution,  history  and  conaittaent  of  resources,  per- 
foraance  analysis,  and  accounting.  One  output  file  inter- 
faces  with  a  plotter  to  provide  critical  path  analysis. 

Other  reports  are  in  either  tabular  or  graphical  fora  and 
are  easily  read  and  interpreted.  The  Nichols  systea  also 
offers  an  optional  generalized  REPORT  WRITER  add  on  to  allow 
the  user  to  design  their  own  reports. 

The  weakness  in  the  Nichols  reporting  structure  lies 
in  the  fact  that  they  measure  progress  via  percent  completed 
rather  than  milestones  completed  which  can  be  very  mislead¬ 
ing.  The  variance  indicators  are  a  key  attraction,  drawing 
managements  attention  to  areas  that  are  off  target. 


2-  g.2st.Ia{2mU0S 

Prices  in  effect  as  of  the  writing  of  this  thesis 
are  as  follows: 


BUT 

Lease/Purchase 

M5500  Basic  Systea 

$25,000 

$  15, 000/yr 

plus  1  years  maintenance 

n/a 

$  1, 000/yr 

total  (1  year) 

$16,000 

Cost  to  purchase  after 

1  year 

n/a 

$11,500 

OPTIONAL  SOFTWARE  AVAILABLE 

(not  available  as 

lease) 

REPORT  WRITER 

S  5,000 

Interactive 

510,000 
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Package  price  includes: 

object  code  (source  will  be  delivered  on  tape  upon  receipt  of 
payment) 

technical  docuaentation  (1) 
user  manuals  (5) 

5  days  of  on  site  training 
input  forms 

1  year  maintenance  with  purchase 
3.  Additional  Inforaation 

'Tektronics,  a  production  facility  that  aacmg  other 
things  produces  terainals.  N5500  was  originally  installed 
on  a  CYBEH  73;  but  due  to  work  load  constraints,  they 
switched  to  their  CYBEH  175.  This  action  resulted  in  faster 
turnaround  time.  The  operating  system  being  utilized  is  NOS 
level  509. 

Contact  was  made  with  Ns.  Charlene  Hadiman,  who  is 
the  data  base  administrator  for  the  Product  Safety  Division. 

[Hef.  21]  She  is  responsible  for  data  entry  and  interpreta¬ 
tion  in  support  of  the  N5500  applications.  Ms.  Nadiman 
indicated  that  they  were  very  pleased  with  the  N5500  pack¬ 
age.  Their  input  is  done  via  terminal  and  then  batched  into 
the  system  for  processing.  All  data  entry  and  interpreta¬ 
tion  is  done  by  Ns.  Nadiman  and  she  says  this  is  a  full  time 
job  considering  the  number  of  pro jects/instruments  she  works 
with  (over  350) .  Inputs  from  project  managers  is  very 
straight  forward  and  involves  entries  on  a  pre-printed  form. 


Only  two  negative  aspects  were  reported.  First,  that  the 
previous  version  of  the  user  manual  was  difficult  to  inter¬ 
pret.*  The  second  problem  area  was  in  the  error  handling 
mechanism.  Errors  are  flagged  and  continue  to  be  flagged 
until  corrected;  however  there  is  no  indication  as  to  the 
type  of  error.  Error  correction  may  prove  to  be  very  time 
consuming  if  the  error  is  not  readily  apparent. 

Ns.  Nadiaan  indicated  that  their  staff  would  be 
happy  to  discuss  the  package  and  its  implementation  further 
with  FN07  staff.**  Ns.  Cindy  Bong,  marketing  representative 
for  Nichols,  has  indicated  that  there  is  a  good  chance  that 
N5500  will  be  converted  to  NOS/BE  for  another  customer  in 
the  near  future  [Ref.  22]. 

D.  NSP's  PROJECTNANAGER  [Hef.  23] 

1.  Seneral.lnformation 

PROJECTNANAGER  was  marketed  originally  in  1972  under 
the  name  PNACS.  It  is  a  batch  processing  system  which  main¬ 
tains  3  major  files:  the  resource  file,  the  activity  file, 
and  the  project  files.  Generally,  the  resource  file  and  the 
activity  file  need  only  be  set  up  once.  The  project  file 

*Nichols  has  released  a  new  version  of  the  user  manual: 
however  Ns.  Nadiaan  has  not  used  it  long  enough  to  evaluate 

**Contact  point  is  Imants  Goltz,  manager  of  software 
support,  at  (503)  627-4675. 
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activity  file  need  only  be  set  up  once.  The  project  file 
contains  the  project  plan,  estimates,  progress  to  date,  and 
new  projects  as  required.  Projects  can  be  broken  down  into 
subproject  levels  called  tasks. 

PROJECTMANAGER  requires  periodic  updating  of  work 
accomplished  and  costs  incurred.  The  user  selects  the 
reporting  period.  Mandatory  entries  are  resource,  project, 
and  activity  codes.  Optional  entries  include  task,  rate  of 
pay,  computer  use  codes  as  well  as  various  expence  catego¬ 
ries  and  projection  data  items. 

Input  can  be  by  card,  or  card  image  on  magnetic 
media,  paper  tape,  or  on-line  data  entry.  All  input  tran¬ 
sactions  are  read  into  the  system  by  a  data  validation  pro¬ 
gram,  which  carries  out  exhaustive  validation  of  each  input 
record  and  rejects  any  erroneous  data.  A  report  is  produced 
by  the  program  so  that  all  detected  errors  are  clearly 
described  to  the  user  for  correction  and  resubmission. 

PROJECTMANASER  output  consists  of  3  sain  types: 
validation  reports,  file  content  listings,  and  user  selected 
progress  reports. 

Validation  reports  are  produced  whenever  data  is  entered. 
All  input  information  is  printed  including  error  codes  and 
pointers  that  identify  incorrect  items. 
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File  content  listings  are  obtained  on  demand  in  standard 
fornat  and  are  of  particular  interest  to  those  who  control 
code  allocation  and  related  tasks. 

Progress  reports  can  custoaize  the  system  to  the  needs  of 
the  organization.  The  number  and  type  of  the  output 
reports  is  determined  by  the  user. 

2.  Cost  Information 

The  PROJECTS AM  AGEE  package  can  be  purchased  for 
$8,000.  The  package  includes: 

Object  code  (on  tape) 

1  days  on-site  training  and  advise 
1  set  of  documentation 

3.  uaiUo  aalJLaf  aaalAaa 

Because  of  the  relatively  low  cost,  this  package  was 
included  for  consideration,  even  though  it  has  not  been 
implemented  on  CDC  equipment  and  will  require  some  in-house 
effort.  The  package  was  written  in  COBOL  for  IBM  equiment; 
but  has  been  coverted  to  operate  on  Burroughs,  Honeywell, 
and  ICL  equipement.  a  recent  conversion  from  IBM  to  ICL 
DME/V  took  one  user  group  17  days.  Larry  Hagg,  West  Coast 
Region  Manager  fo  MSP,  has  indicated  that  FMOC  could  obtain 
the  source  program  at  no  additional  charge,  if  they  wished 
to  convert  the  package  themselves.  [Ref.  24]  The  code  should 
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ba  examined  closely  by  FNOC  analysts  to  determine  if  there 


would  be  any  problem  in  conversion.  Generally  speaking, 
conversion  of  COBOL  programs  is  relatively  easy.  The  prob- 
lea  is  that  once  FNOC  aakes  this  conversion,  BSP  will  not  be 
able  to  provide  the  maintenance. 

E.  OTHER  PACKAGES  EXAMINED 

Other  packages  examined  and  subsequently  eliminated  are 
included  here  to  assist  FNOC  in  acquisition  in  the  event 
that  they  choose  to  follow  through  on  a  PICS.  QUICK  TROL, 
marketed  by  Quality  Data  Products  Inc.,  is  written  in 
assembly  language  and  can  not  be  adapted  to  CDC  equipment . 
PROJECT  MONITOR,  Marketed  by  Program  Products  Inc,  was 
unresponsive  to  requests  for  additional  information.  Infor¬ 
mation  on  PC  70,  marketed  by  Atlantic  Software  Inc.,  was 
received  to  late  to  include  in  this  analysis.  It  is  recom¬ 
mended;  however  that  should  FNOC  consider  the  purchase  of  a 
software  package,  Atlantic  Software  Inc.  Be  given  an  invita¬ 
tion  for  bid. 
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VIII.  ALTERNATIVE  COURSES  OF  ACTION 


A.  MANUAL  ALTERNATIVES 

The  alternatives  requiring  the  least  tine,  effort,  and 
resources  are  those  that  require  little  change  to  current 
aethods;  however  these  alternatives  may  not  be  the  aost 
desirable.  Two  annual  alternatives  are  presented  here 
because  they  are  considered  viable  alternatives. 

ALTERNATIVE  1:  COHTIBOB  AS  IS 

The  obvious  advantage  to  this  alternative  is  that  it 
requires  no  effort  ana  no  cost.  That  is,  no  direct  cost. 

It  could  cost  in  teras  of  the  efficiency  and  effectiveness 
of  the  organization.  With  the  exception  of  the  work  unit 
reporting,  which  is  done  twice  a  year,  there  is  no  foraally 
defined  reporting  structure  for  project  nanageaent  at  FNOC. 
Foraal  reporting  psraits  ready  coaparison  of  progress  with 
plans  and  easures  a  uniforaity  and  consistency  of  informa¬ 
tion  throughout  the  project.  It  also  provides  a  historical 
record  of  tbue  project.  Failure  to  keep  adequate  well  struc¬ 
tured  reports  aakes  it  very  difficult  when  others  are  forced 
to  assuae  aanageaent  duties.  Personnel  turnover  at  FNOC  is 
high  due  to  the  military  environaent.  It- is  therefore 
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critical  that  records  allow  the  new  project  manager  to  trace 
what  has  been  done  and  what  remains  to  be  done  in  the  pro¬ 
ject.  Many  projects  span  several  years,  so  the  chance  of 
turnover  in  project  personnel  is  high.  Use  of  civilians  in 
hey  positions  eases  this  problem  somewhat;  but  does  not  eli¬ 
minate  it  all  together. 

With  no  complete  historical  records  of  projects,  FNOC 
will  find  great  difficulty  in  presenting  and  defending  their 
actions  in  case  of  contract  dispute  and  litigation.  Histor¬ 
ical  records  of  a  project  can  also  assist  the  project  man¬ 
ager  in  planning  future  projects  and  hopefully,  in  avoiding 
mistakes  made  in  prior  projects. 

ALTEHIITIVB  2:  ENHANCED  MANUAL  SYSTEM 

Enhancement  of  the  current  manual  system  could  serve  to 
alleviate  some  of  the  problems  noted  previosly.  This 
enhancement  can  take  the  form  of  in-house  establishment  of 
definitions  and  procedures  or  perhaps  the  purchase  of  a  pro¬ 
ject  management  methodology. 

In-house  enhancement  means  those  who  establish  the  meth¬ 
odology  will  be  intimately  familar  with  the  FNOC  environ¬ 
ment;  however  they  nay  not  have  the  project  management 
expertise  that  might  be  available  on  the  outside.  Staff 
tine  will  3till  be  required  to  determine  and  put  into  effect 
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the  methodology .  This  may  be  time  that  could  be  better 
spent  elsewhere. 

There  are  several  methodologies  marketed  that  would  pro¬ 
vide  assistance  in  establishment  of  a  project  management  and 
control  system.  Spectrum,  marketed  by  Spectrum  Interna¬ 
tional  Inc.  of  Los  Angeles, CA.,  and  SDH/70,  marketed  by 
Atlantic  Software  Inc.  of  Philadelphia,  PA.,  are  two  such 
methodologies.  Spectrums  price  ranges  from  $32,000.  Price 
is  dependent  on  the  number  of  programmers  and  analysts  that 
must  be  trained.  For  a  staff  of  40-50,  the  price  goes  up  to 
$50,000  ,  which  includes  the  16  days  of  training.  The 
SDH/70  price  of  $30,000  includes  training  and  the  availabil¬ 
ity  of  a  24  hour  hot  line.  These  prices  are  relatively  high 
in  comparison  to  the  automated  packages  available.  They 
also  fail  to  eliminate  a  key  problem,  relating  to  timeliness 
and  accuracy  of  reports.  The  amount  of  correlation  and 
calculations  needed  to  produce  some  reports  preclude  the  use 
of  manual  methods.  Speed  and  accuracy  are  vital  parts  of 
progress  reporting  and  are  primary  benefits  accorded  by  a 
computer. 

B.  AUTOMATED  ALTERNATIVES 

Projects  involve  the  deployment  of  a  number  of  person¬ 
nel,  equipment,  and  money,  and  the  integration  of  activities 
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to  achieve  soae  predetermined  aia.  This  neans  that  these 
activities  aust  have  been  pre-planned,  and  the  degree  of 
success  achieved  depends  to  a  large  extent  on  the  effective¬ 
ness  of  the  planning.  There  are  aany  types  of  projects  and 
activities  that  do  not  lend  theaselves  to  annual  control 
methods,  for  example,  those  that  involve  a  large  number  of 
organizations  or  people.  Additionally,  the  interdependen¬ 
cies  of  the  various  parts  of  the  plan  nay  be  to  complex  for 
an  individual  to  monitor  and  traditional  methods  of  repre¬ 
sentation  <ie.  bar  charts  or  schedules)  may  not  represent 
the  plan  effectively.  Finally,  the  project  may  span  long 
lengths  of  time,  making  it  difficult  to  track  manually. 

Hith  these  points  in  mind,  it  becomes  necessary  to  consider 
alternatives  that  provide  for  soae  neans  of  automated  assis¬ 
tance  for  PICS.  The  following  alternatives  provide  that 
capability. 

ALTERNATIVE  3:  IN-BOOSE  DEVELOPMENT 

There  are  several  advantages  to  in-house  development. 
Pirst,  the  system  aust  be  acceptable  within  the  user  envi¬ 
ronment  and  to  the  user  group.  By  developing  it  in-house 
there  is  a  greater  opportunity  for  user  involvement.  The 
user  aust  identify  the  new  system  with  their  operational 
requirements  from  the  start,  this  too  is  made  more  viable  by 
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in-house  development.  Change  needs  to  be  self-moti viated  if 
it  is  to  be  successful  and  long  lasting.  The  organization 
must  take  the  responsibility  for  and  be  committed  to  the  new 
program. 

In-house  system  development  is  rarely  cost-effective 
when  compared  with  outside  purchase.  Valuable  system  usage 
time  is  lost  while  the  in-house  system  is  developed.  Due  to 
the  developmental  nature,  there  is  a  degree  of  uncertainty 
as  to  the  cost  and  schedule  completion.  Additionally,  staff 
must  be  allocated  to  the  development,  who  may  be  utilized 
more  effectively  on  organization  specific  development  (ie. 
oceanographic  and/or  meterological  products) .  The  mainte¬ 
nance/enhancement  cost  of  in-house  software  is  normally  in 
the  region  of  50*  of  the  original  cost  per  year.  While  it 
is  true  that  in-house  systems  may  be  geared  more  closely  to 
the  original  requirements;  this  may  make  them  less  flexible 
when  ammendments  become  necessary. 

AITEHHATIVB  4:  PURCHASE  SOPTWARB  PACKAGE 

It  would  be  advantageous  to  puchase  a  software  package 
rather  than  suffer  the  expense  and  time  delay  that  would  be 
necessary  to  design  and  program  a  PICS  specifically  for  FNOC 
applications.  Because  the  vendor  is  able  to  spread  his 
package  development  costs  across  a  number  of  installations; 
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it  represents  a  real  discount  on  the  investment  required  for 
a  siailar  development  in-house.  Funds  can  be  budgeted  and 
an  installation  date  scheduled  with  a  great  deal  more  cer¬ 
tainty.  The  organization  also  gains  the  value  of  the  ven¬ 
dors  project  management  expertise  and  the  experience  gained 
by  installations  at  other  sites.  Additionally,  many  of  the 
software  bugs  will  have  been  corrected.  The  problem  is  that 
the  organization  may  not  be  as  receptive  to  a  package  that 
will  change  their  methods.  It  will  be  important  to  make  the 
transition  as  painless  as  possible.  Many  of  the  packages 
allow  the  user  to  define  terms  and  establish  procedures  con¬ 
sistent  with  those  currently  in  use.  The  organization  must 
assure  that  documentation  is  complete  since  they  may  be 
required  to  maintain  it  or  puchase  maintenance  services  from 
the  vendor  at  additional  costs. 

Purchase  of  a  software  package  will  probably  require 
purchase/lease  of  a  COBOL  compiler  since  very  few  packages 
are  written  in  FORTRAN.  Contact  was  made  with  Hr.  Ken  Gat- 
liffe,  local  CDC  representative,  concerning  pricing  informa¬ 
tion.  A  COBOL  compiler  for  a  CYBER  170,  175  or  CDC  6600 
would  cost  <12,540  to  purchase  or  may  be  leased  for  $310  a 
month  plus  a  one  time  fee  of  $140  [Ref.  25]. 
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ALTERNATIVE  5:  BSTZ7E  OLD  HIS 
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The  PNOC  MIS  system  was  originally  designed  for  use  by 
one  departaent  head  and  later  adopted  for  command-wide  use. 
It  was  not  designed  with  the  organizations  overall  objec¬ 
tives  in  aind.  It  was  designed  to  fill  a  particular  need  at 
that  tiae.  The  designer  of  the  program  and  those  that  had 
been  directly  involved  in  its  operation,  have  long  since 
departed  PNOC.  Documentation  is  not  complete  and  therefore 
revision  and/or  updating  will  not  be  an  easy  task.  It  will 
take  a  great  deal  of  tiae  for  someone  to  becoae  faailar 
enough  with  the  code  to  start  to  adapt  it.  Additionally, 
there  are  still  some  very  negative  attitudes  remaining  con¬ 
cerning  this  MIS  .  It  was  never  well  defined,  inputs  and 
updates  were  erratic,  and  the  system  only  received,  sporadic 
attention  by  upper  management.  Not  only  did  middle  manag¬ 
ers,  who  were  required  to  submit  the  update  information,  not 
derive  any  benefits  from  the  system;  but  they  saw  that  upper 
management  was  not  utilizing  it.  They  saw  their  efforts  as 
wasted,  and  when  they  did  see  any  outputs  from  the  system  it 
was  not  current  information. 

This  system  required  at  least  1  full  tiae  administrator, 
although  2  would  be  more  realistic  considering  the  amount  of 
data  entry  required.  If  the  documentation  were  clear  enough 
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and  only  minor  changes  were  needed,  this  would  clearly  be 
an  economical  approach.  The  ramifications  of  the  staff  atti¬ 
tude  problem  is  indeed  difficult  to  predict. 

ALTERNATIfE  6:  DEDICATED  Hill 

Initially  this  alternative  will  be  the  most  costly.  Not 
only  will  the  organization  need  to  purchase  the  computer; 
they  will  also  have  to  purchase  or  develop  the  software 
package.  This  alternative  will,  in  all  liklihood,  take  more 
time  from  decision  to  installation  than  the  others.  It  will 
also  require  the  involvement  of  more  FNOC  technical  person¬ 
nel  in  the  acquisition,  due  to  the  hardware. 

This  alternative  has  several  distinct  advantages.  Hav¬ 
ing  a  dedicated  or  semi-dedicated  mini  makes  access  easier 
and  allows  for  continued  operations  when  the  main  computer 
system  goes  down  or  is  over  loaded.  It  also  allows  the  pos¬ 
sibility  of  a  wider  selection  of  software  packages.  Greater 
benefits  may  be  derived  by  utilizing  the  mini  for  other  man¬ 
agement  and/or  administrative  applications,  such  as  an 
inventory  control  system,  electronic  mail,  etc.  It  also 
would  open  up  a  wider  range  of  possible  software  packages 
for  this  and  other  applications. 
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IX. 


Project  aan&gers  are  responsible  for  planning  and  sche¬ 
duling  various  projects  and  assignments.  They  aust  face 
changing  priorities  and  resources  and  respond  appropriately. 
Changes  and  reevaluation  of  projects  involving  new  priori¬ 
ties,  resource  availability  (or  lack  of  availability) ,  new 
dependencies,  ect.  aake  Management  of  on  going  projects  a 
full  tiae  job. 

&  highly  coaplex  and  expensive  undertaking  like  a  soft¬ 
ware  developaent  project  requires  careful  planning.  The 
project  aanager  can  not  hope  to  schedule,  measure,  and  con¬ 
trol  complex  programming  activity  without  a  formalized, 
highly  developed  plan.  All  projects  need  planning.  In  aost 
cases  this  involves  a  detailed  breakdown  of  all  the  tasks 
which  aake  up  a  project  to  ensure  that  realistic  schedules 
of  anticipated  progress  can  be  prepared.  Bach  task  needs  to 
be  of  an  easily  identifiable  and  self  contained  nature  so 
that  aeasureaent  of  progress  is  aade  as  simple  as  possible, 
ffithin  each  task  self  contained  check  points  aust  be  estab¬ 
lished  so  that  comparison  of  actual  progress  against  planned 
progress  can  be  aade  at  meaningful  intervals. 
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The  only  realistic  way  to  be  in  control  is  to  see  regu¬ 
lar  evidence  of  progress  (evidence  of  tasks/jobs  completed) . 
Documents  to  control  projects  must  take  into  account  a 
balance  between  the  need  for  control;  and  the  desire  to  keep 
fora  filling  to  a  minimum. 

One  of  the  more  important  features  of  the  project  con¬ 
trol  system  is  the  method  of  reporting.  It  should  serve  to 
formalize  the  kind  of  casual  reporting  that  occurs  in  all 
organizations.  Formal  reporting  permits  ready  comparison  of 
progress  with  plans  and  ensures  a  uniformity  and  consistency 
of  information  throughout  the  project. 

It  is  the  author's  opinion  that  FSOC  needs  a  better 
defined  and  more  uniform  project  information  and  control 
system.  The  current  formal  reporting  mechanism  and  the 
informal  reporting  to  the  commanding  officer,  are  neither 
adequate  nor  efficient.  Verbal  reports  to  the  commanding 
officer  are  time  consuming  and  may  not  be  the  best  presenta¬ 
tion  node.  Presentation  of  one  project  without  a  view  of 
haw  it  fits  into  the  overall  project  environment  nay  give  a 
distorted  picture.  Use  of  the  word  processor  for  anything 
other  than  processing  textual  information  is  not  authorized, 
therefore  correlation  of  information  must  be  accomplished  in 
some  other  manner  [Ref.  26  6  27]. 
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It  is  also  the  author's  opinion  that  correlation  and 
presentation  of  project  inforaation  can  best  be  acconplished 
by  an  automated  PICS. 

Based  on  inforaation  obtained  in  the  preliminary  analy¬ 
sis,  the  author's  preference  is  for  the  PAC  II  software 
package.  This  is  based  primarily  on  2  findings.  First,  the 
fact  that  this  system  has  been  implemented  successfully  on 
CDC  equipment  and  the  same  operating  system  as  utilized  at 
FNOC.  Additionally,  this  package  appears  to  be  flexible 
enough  to  meet  current  and  possible  fututre  needs  of  FNOC. 

Although  it  is  the  author's  opinion  that  adoption  of  an 
automated  project  information  and  control  system  at  FNOC  is 
a  desirable  action;  and  that  this  action  if  properly  imple¬ 
mented  will  enhance  FNOC's  effectiveness  and  efficiency;  the 
following  must  serve  to  qualify  this  recommendation. 

The  first  and  primary  consideration  for  implementation 
is  that  top  level  management  at  FNOC  must  make  the  decision 
to  give  full  and  active  support  to  such  a  system.  Without 
this  support  the  system  has  very  little  chance  for  success. 
Positive  action  must  be  taken  if  requirements  are  not  net  by 
principle  investigators  and  project  managers.  A  steering 
committee,  whose  primary  function  is  to  review  procedures 
and  assure  compliance,  night  be  considered. 
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Once  the  decision  is  made  to  provide  this  support,  an 
evaluation  group,  conposed  of  programmers,  analysts,  project 
managers  and  principle  investigators,  should  be  formed.  The 
Executive  Officer  and/or  the  Commanding  Officer  may  also 
wish  to  be  a  part  of  this  group  since  they  are  also  users. 
Acquisition  must  go  out  for  cospetitve  bid  unless  sole 
source  can  1>e  justified,  which  is  unlikely  in  this  case. 
Distributors  of  all  packages  reviewed  offered  demonstrations 
and/or  presentaions  of  their  package  capabilities.  It  may 
be  appropriate  to  allow  vendors  to  make  a  presentation  prior 
to  the  decision  to  automate.  It  would  certainly  serve  to 
provide  visual  proof  of  what  an  automated  system  can  and  can 
not  do. 

Once  a  package  is  selected;  it  is  recommened  that  in 
order  to  minimize  the  disruption,  FNOC  not  convert  in-pro¬ 
cess  projects  to  the  new  system.  It  would  be  best  to  start 
only  new  projects  on  the  new  system.  This  will  minimize  the 
burden  on  the  staff  and  management  personnel  and  allow  for  a 
smoother  transition. 

The  development  and  implementation  of  a  project  control 
system  is,  in  itself  a  project.  A  great  deal  of  extra 
effort  is  needed.  Just  how  detailed  any  project  control 
system  becomes  is  a  function  of  the  system  size  and 
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complexity  of  the  organization  in  which  it  is  being  applied. 
Generally,  whatever  the  effort,  the  cost  of  a  typical  soft¬ 
ware  development  project  is  reason  enough  to  justify  it. 


APPENDIX  A 


Requirements  Checklist 

SEMMi  ISEQMAXION 

This  checklist  is  part  of  a  study  being  conducted  on  pro¬ 
ject  management  and  control  at  FNOC.  The  information  on  the 
following  pages  was  acquired  as  a  result  of  interviews  con¬ 
ducted  with  a  select  group  of  key  FNOC  project  personnel. 

The  question  posed  was;  what  information  requirements  and/or 
capabilities  would  you  like  to  see  in  a  project  management 
and  control  system  at  FNOC  (either  automated  or  manual) . 

The  requirements  listed  on  the  following  pages  represent 
ONLY  those  that  were  mentioned  during  the  personal  inter¬ 
views.  The  list,  in  all  probability,  does  not  cover  all  pos¬ 
sible  requirements.  It  is;  however,  a  starting  point. 

The  requirements  have  been  grouped  according  to  six 
general  functional  categories  to  facilitate  an  orderly 
presentation  mode.  This  categorization  was  based  strictly  on 
the  subjective  judgement  of  the  interviewer.  Some  of  the 
requirements  could  very  well  fit  into  more  than  one  of  the 
categories;  however  they  are  listed  only  once  for 
simplicity. 
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tour  cooperation  is  requested  in  reviewing  and  responding 
to  the  checklist  iteas  on  the  following  pages.  Each  itea 
requires  two  checks;  one  in  response  to  whether  or  not 
you'll  use  the  inforaation  and  one  in  regards  to  how  you 
would  prefer  it  to  be  stored. 

If  after  reviewing  these  reguireaents  you  can  add  to  the 
list  please  do  so;  your  input  will  be  a  valuable  addition. 
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ONTRACT  INFORMATION 


DESCRIBE  TOUR  USE  OF  INFO  WHERE  SHOULD  IT  BE  STORE 


DP  CONSUMABLES  USED 


GENEBAL  CAPABILITIES  BBQ0IB8D 
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